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DETAILED ACTION 

1 . This action is responsive to communications: response filed 3/7/06 to the 
application filed on 6/16/00. priority filed 6/16/99. 

2. Claims 1-8. 11.19-20. 22-23, 27-28. 36 are pending in the case. Claims 1.11, 
19. 26, and 36 are independent claims. 



Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which fomns the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 103(c) and potential 35 U.S.C. 102(e). (f) or (g) 
prior art under 35 U.S.C. 1 03(a). 
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5. Claims 1-8, 11,19-20, 22-23, 27-28, 36 remain rejected under 35 U.S.C. 103(a) 
as being unpatentable over Markus et al. (US Pat No. 6,490,601 B1, 12/3/02, filed 
1/1 5/99) in view of Mohan et al. (US Pat App Pub No. 2003/0140312 A1 , 7/24/03. filed 
11/26/02, priority 5/14/99). 

Regarding independent claim 1, Markus discloses: 

- creating a user profile associated with a user, wherein said user profile includes 
user data (figure 6, #604, #608: retrieving user's raw data profile and merging 
user's raw data profile with mapping table inherently show that each of a plurality 
of user profiles are created and stored in memory so that the user data profiles 
including user data can be retrieved or used later) 

- obtaining an electronic form having a field to be completed (col 5, lines 1-12, 29- 
35: "a form mapping containing a set of associations between fields in the 
electronic form "...enabling automatic insertion of user information into an 
electronic form having multiple fields . . .") 

- dynamically generating a form map, wherein the form map identifies an 
association between the user data and the field in the electronic form (col 5, 
lines 1-55: "A form mapping containing a set of association between fields in the 
electronic form . , . Each raw data file containing data strings, each data string 
corresponding to a pre-named field. Each raw data file is associated with a 
registered user ... The form mapping is utilized to attach a data sthng to the field 
in the electronic form where the pre-named field and the field in the electronic 
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form have been previously matched or mapped ... a form mapping is utilized to 
attach a data string to the field in the electronic form ... comparing data relating 
to the field in the electronic form.."] since each user lias different raw data file, 
generating such form map varies according to each user data file, said 
generating is performed dynamically according to each user; col 14, line 30 to 
col 16, line 28: "... the user cookie is used to obtain the user's raw data, which 
includes actual data values and preferences associated with each data value. 
The practices mentioned above associated with legacy names and the 
preferences associated with user raw data values are stated in terms of 
conditions mapping data into the form is performed according to the form 
map where the fomn map (or the form mapping) varies according to various 
conditions and preferences from each user inherently shows that the form map is 
generated dynamically according to various conditions and preferences from 
each user) 

- obtaining the user profile from a fill server (col 5, lines 29-41, 45-55: "a se/ver for 
enabling automatic insertion of user information into an electronic form having 
multiple fields ...The server contains a memory area storing multiple raw data 
profiles where each raw data profile corresponds to a registered user "the 
raw data profile includes several standard field names, each standard field name 
having a corresponding data string and a use-preference data item determined 
by a registered user...") 
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" completing the field according to the form map with the user data (figure 4B, 
#440, [0099]: "Browser transmits filled out electronic form documenf inherently 
shows completing a field according to the form map for a field in the electronic 
form with the user data in the raw data file; col 6, line 63 to col 7, line 23: filling 
a form with data from the privacy bank shows completing the field in the form 
with the user data according to the form map) 
Markus does not disclose: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field 

- updating the user profile with the user entered data 
Mohan discloses: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field ([0095]: user enters data not found in the user's 
profile to the form) 

- updating the user profile with the user entered data ([0095], [0096], [01 02], 
[0092]: storing the form submitted with user-entered information to the IIM at 
server where the user-entered data can be data not found in the user's profile 
implies that data in the user profile at IIM is updated with the user-entered data) 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
was made to have combined Mohan into Markus for automafically updating the user 
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profile with user-entered data which is not found in the user profile. Thus, users do not 
have to remember to update the user profile every time they enter a new data not in the 
user profile before. 

Regarding claim 2, which is dependent on claim 1, Markus discloses that obtaining a 
user profile includes: 

- transmitting a user identification and a signature of the electronic form to a fill 
server (col 8, lines 1-14: "User 302 informs privacy bank server 308 of the 
identity of tlie user and of wtiich Web site and which form on that Web site (if 
more than one) the user wishes to have filled in. This information is transmitted 
to privacy banl< server . . .") 

- obtaining the user profile from the fill server, wherein the user profile corresponds 
to the user identification (col 8, lines 40-64: the raw data profile storage area 
328, one of the components of the privacy bank server which enables to fill in the 
electronic form on a remote user computer, includes the data profile for each 
registered user) 

Regarding claim 3, which is dependent on claim 2, Markus discloses that the user 
identification includes a user ID and a user password (col 8, lines 40-64: "a registered 
user has an unique account that can be used as an identifier and a password..."). 

Regarding claim 4, which is dependent on claim 2, Markus discloses that the electronic 
form signature includes a text string having a unifomi resource locator of the electronic 
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form (col 7, lines 40-62: "a purchasing form, typically an HTML document, is returned 
and downloaded into and displayed in a browser window..."; the fact that the purchasing 
form is a HTML document inherently shows that the HTML document, which includes 
the electronic form, has an unifomi resource locator; col 11, lines 43-49: the user 
identifier and the URL for identifying the document containing the form; col 13, lines 38- 
48: the identifier of the electronic form contains the identifier of the merchant's Web site 
in the form of a URL). 

Regarding claim 5. which is dependent on claim 4, Markus discloses that the electronic 
form signature includes a descriptor of the one or more fields of the electronic form (col 
17, lines 8-15: the name strings or field names or guides to entering data in an 
electronic form; col 9, lines 1-13: the field names are the descriptors of the fields in an 
electronic form). 

Regarding claim 6, which is dependent on claim 4, Markus discloses that the electronic 
form signature includes a descriptor of form field requirements (col 11, lines 39-49: the 
fact that the URL which is used by the privacy bank server to determine how the 
electronic form document should be filled implies that said URL, which is the electronic 
form signature, contains a descriptor of form field requirements). 

Regarding claim 7. which is dependent on claim 1 . Markus discloses that the user 
profile is represented by a graphical icon on a display screen and wherein the user data 
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is transferred to the electronic form on manipulation of the graphical icon within the 
display screen (col 11, lines 15-22: ".. by clicking on tlie autofill button, the user allows 
the browser to execute the shippable code or profile stored thereon,," ), 

Regarding claim 8. which is dependent on claim 1 , Markus discloses that the user 
profile includes shippable code embodying the user data corresponding to the fields of 
the electronic form, and wherein completing at least one of the fields of the electronic 
form includes executing the shippable code to complete at least one of the fields of the 
electronic form (col 5, lines 29-44). 

Regarding claim 11, which is dependent on claim 1, Markus discloses: 

- displaying a second application indicative of the user profile containing data 
corresponding to at least the field of the electronic form according to the form 
map (figure 4A, #408-418: the fact that the browser for displaying the electronic 
form connects with the privacy bank and gets cookie and user data 
corresponding to the cookie from the privacy bank server inherently shows that 
the user profile data of the privacy bank server is displayed in a different window 
in a second application; col 10, lines 1-35 and col 8, lines 19-39) 



Regarding claim 19. which is dependent on claim 1, Markus discloses: 
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- generating a fill bundle corresponding to a merger of data within at least one of 
the user profile and the form map corresponding to a form signature, wherein the 
fill bundle is embodied in a graphical representation (figure 6, #608 Server 
merges mapping table with user's raw data profile, #610 Server converts merger 
into shippable code and col 13, line 49 to col 14, line 29: generating a 
shippable code in the form of a JavaScript program where the shippable code, 
converted from the merger of legacy bank name and raw data value associated 
with one of a plurality of users, is used to fill in the form on the user browser; the 
shippable code bundles data for filing the electronic form, and is corresponding to 
a fill bundle) 

Regarding claim 20, which is dependent on claim 1, Markus discloses obtaining the 
user profile corresponding to a user identification from a database having one or more 
user profiles organized according to the user identification (figures 3A-B and col 8, 
lines 40-64: raw data profile contains sets of data relating to registered user of the 
privacy bank service where a registered user has a unique account number as a user 
identification). 

Regarding claim 22, which is dependent on claim 1 , Markus discloses that if the form 
map database does not have a form map corresponding to the form signature, 
generating a new form map based upon the form signature (col 13, line 49 to col 14, 
line 4: the privacy bank server uses the URL or other identifier for the specific form to 
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be filled out to retrieve a mapping of each field name in the electronic form to privacy 
bank standardized names; the merchant submits one or more forms to privacy bank 
which then examines each field name in the forms and matches it with a privacy bank 
field name; the fact that if the legacy name does not match the privacy bank field 
names, then the privacy bank user raw data can be updated to include the legacy name 
based upon the identifier of the form indicates that when the privacy bank server whose 
form map database does not have the form map of the newly submitted form from the 
merchant, the privacy bank raw data is updated to include the newly created form map 
of the new form based upon the corresponding URL or the form signature). 

Regarding claim 23, which is dependent on claim 19, Markus discloses that the fill 
bundle includes shippable code containing commands for completing one or more 
corresponding fields of the electronic fomri (col 14, lines 5-29: "normally browser 
programs have a JavaScript component that is manipulable by JavaScript commands. 
These JavaScript commands in the shippable code are used to fill in the electronic form 
on the browser, a technique well known in the field of Internet and Java 
programming.."). 

Regarding claim 27, which is dependent on claim 1 , Markus discloses that the system 
further comprises a user information server in communication with the fill server and 
providing user profile data to the fill server (col 7, line 63 to col 8, line 39: the fact that 
the Markus system has the capability of providing user profile data and creating fill 
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bundle embodied in shippable code for filling data in the user profile to electronic forms 
in a remote computer inherently shows that the Markus system includes a user 
information server in communication with the fill server). 

Regarding claim 28. which is dependent on claim 1. Markus discloses a form map 
server in communication with the fill server and providing form maps corresponding to at 
least one field of an electronic form, wherein a graphical representation includes a 
merger of the form map and the user profile data (figure 6 and col 13, line 49 to col 
14, line 29: the merger of mapping table, including form map, with user's raw data 
profile in a user's browser shows that the graphical representation of the browser 
window includes the merger; the mapping table retrieved from the privacy bank 
database connected to the user's browser where to display the form and the web site 
that contains the form and to fill in the form inherently shows that the privacy bank 
database which stores the table of form mapping is considered as a form map server, 
and the privacy bank server is where to create the fill bundle embodied in shippable 
code is considered as the fill server). 

Regarding independent claim 36, Markus discloses: 

- creating a user profile associated with a user, wherein said user profile includes 
user data (figure 6, #604, #608: retrieving user's raw data profile and merging 
user's raw data profile with mapping table inherently show that each of a plurality 
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of user profiles are created and stored in memory so that the user data profiles 
including user data can be retrieved or used later) 

- obtaining an electronic form having at least a field to be completed (col 5, lines 
1-12, 29-35: "a form mapping containing a set of associations between fields in 
the electronic form "...enabling automatic insertion of user information into an 
electronic form having multiple fields ...") 

- dynamically generating a form map, wherein said the form map identifies an 
association between the user data and the field in the electronic form (col 5, 
lines 1-55: "A form mapping containing a set of association between fields in the 
electronic form ... Each raw data file containing data strings, each data string 
corresponding to a pre-named field. Each raw data file is associated with a 
registered user . . . The form mapping is utilized to attach a data string to the field 
in the electronic form where the pre-named field and the field in the electronic 
form have been previously matched or mapped ... a form mapping is utilized to 
attach a data string to the field in the electronic form ... comparing data relating 
to the field in the electronic form.."] since each user has different raw data file, 
generating such form map varies according to each user data file, said 
generating is performed dynamically according to each user; col 14, line 30 to 
col 16, line 28: "... the user cookie is used to obtain the user's raw data, which 
includes actual data values and preferences associated with each data value. 
The practices mentioned above associated with legacy names and the 
preferences associated with user raw data values are stated in terms of 
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conditions ..."; mapping data into the form is performed according to the form 
map where the form map (or the form mapping) varies according to various 
conditions and preferences from each user inherently shows that the form map is 
generated dynamically according to various conditions and preferences from 
each user) 

- obtaining the user profile from a fill server (col 5, lines 29-41, 45-55: "a server for 
enabling automatic insertion of user information into an electronic form having 
multiple fields ..The sen/er contains a memory area storing multiple raw data 
profiles where each raw data profile corresponds to a registered user "the 
raw data profile includes several standard field names, each standard field name 
having a corresponding data string and a use-preference data item determined 
by a registered user,,.") 

- completing the field according to the form map with the user data (figure 4B, 
#440: "Browser transmits filled out electronic form document inherently shows 
completing a field according to the form map for a field in the electronic form with 
the user data in the raw data file; col 6, line 63 to col 7, line 23: filling a form 
with data from the privacy bank shows completing the field in the form with the 
user data according to the form map) 

Markus does not disclose: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field 
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- updating the user profile with the user entered data 
Mohan discloses: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field ([0094]: user enters data not found in the user's 
profile) 

- updating the user profile with the user entered data ([0095], [0096], [01 02], 
[0092]: storing the fomri submitted with user-entered information to the IIM at 
server where the user-entered data can be data not found in the user's profile 
implies that data in the user profile at IIM is updated with the user-entered data) 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
was made to have combined Mohan into Marl^us for automatically updating the user 
profile with user-entered data which is not found in the user profile. Users, thus, do not 
have to remember to update the user profile every time they enter a new data not in the 
user profile before. 

Response to Arguments 

6. Applicant's arguments filed 3/7/06 have been fully considered but they are not 
persuasive. 

Applicants argue that Mohan does not disclose or suggest at least "obtaining user 
entered data from the electronic form, wherein the user entered data is at least one of 
absent from the user profile and different from the user data in a corresponding field, 
and updating the user profile with the user entered data." 
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Examiner respectfully disagrees. 
Mohan discloses: 

- obtaining user entered data from the electronic form, wherein the user entered 
data is at least one of absent from the user profile and different from the user 
data in a corresponding field ([0095]: user enters data not found in the user's 
profile to the fonri) 

- updating the user profile with the user entered data ([0092], [0095], [0096], 
[0102]: storing the form submitted with user-entered information to the Ht\/l at 
server where the user-entered data can be data not found in the user's profile 
implies that data in the user profile at IIM is updated with the user-entered data) 

As in the cited portions above, a user is allowed to enter data not in the user profile 
when filling a form that requests such data ([0095]). Then, when the filled fonn is 
submitted to the destination server, the IIM stores the submitted information to the 
server in the user's transaction database ([0096]). The IIM then updates the information 
added by the user ([0102]). Further, it is noted that the data in the user profile is tested 
to see if any change has been made to the user profile since the transaction in the 
transaction database was recorded and the transaction records are dated as are 
changes to the user profile ([0092]). This shows that changes recorded in the 
transaction database are dated as changes to the user profile. Therefore, when the 
transaction database is recorded with the added information entered by a user, that 
means, changes are added to the transaction database, these changes are also dated 
as the changes to the user profile. 
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Applicants further argue that in Mohan, there is no disclosure that a user profile is 
updated via the transaction database, and if any, such update would render Mohan at 
least partially inoperable. One of the reason provided by Applicants is that if the user 
chooses to remove their social security number from a form after the form has been 
filled, the changed fomri data will be saved to the transaction database, minus the social 
security number. When the same user subsequently fills out the same font, the form will 
not be filled with the social security number, as per the user's preferences. And this is 
not what the user wants. 

The example that Applicants point out is not appropriate to the case that new data, 
which is not present in the user profile before, is entered by users and added to the 
transaction database as in Mohan. The social security number is known, not new data, 
which is not in the user profile before. And even when removing the social security 
number from the form, there is no new data entered compared with the data in the user 
profile as in Mohan. The data then is less than the data in the user profile before, and 
all is known, not new. Therefore, Applicants arguments are not persuasive. 

Conclusion 

7. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

Buhrmann et al. (US Pat No 5,933,778, filed 6/4/96). 
Saccocio et al. (US Pat No 6,944.669, priority 10/22/99). 
Kennedy et al. (US Pat No 6,651.217, filed 9/1/99). 
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Plow et al. (US Pat App Pub No 2003/0028792, filed 8/2/01). 
8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Cong-Lac Huynh whose telephone number is 571-272- 
4125. The examiner can normally be reached on Mon-Fri (8:30-6:00). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Stephen Hong can be reached on 571-272-4124. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-4125. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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